From: "Stefan Stuntz"
Date: Tue, 12 Dec 1995 16:44:28 +0100
X-Mailer: IntuiNews 1.3b Beta 3 (5.11.95)
Subject: Re: Clipping in SubClasses
Message-Id: <64540122@magic.informatik.tu-muenchen.de>
Organization: Home of MUI
Resent-Message-Id: <"n3xuz2.0.TT.1_Upm"@sunsite>
Resent-From: mui@sunsite.Informatik.RWTH-Aachen.DE
Reply-To: mui@sunsite.Informatik.RWTH-Aachen.DE
X-Mailing-List: archive/latest/50
X-Loop: mui@sunsite.informatik.rwth-aachen.de
Precedence: list
Resent-Sender: mui-request@sunsite.Informatik.RWTH-Aachen.DE
Content-Type: text
Content-Length: 1744
X-Lines: 45
Status: RO
Stephen Vermeulen wrote in article <9512111927.AA13480@boris.psg.datap.ca>:
> > Georg Kraemer wrote
> >
> > > 1.) What is the correct way of clipping inside a SubClass ? Currently
> > > I simply set Clipping to the inner of the gadget, but this may be
> > > conflict with Clipping of virtual Groups for example. Of cause
> > > clipping is only done during the DRAW Method.
> >
> > Use MUI_AddClipping()/MUI_RemoveClipping() from muimaster.library, never
> > use InstallClipRegion() in MUI-Windows.
> >
>
> These do not appear in the mui31dev.lha (from AMINET) autodocs, what else is
> missing from them too? Do you have a more up-to-date set of autodocs
> available elsewhere?
Unfortunately not. :(
APTR MUI_AddClipping (struct MUI_RenderInfo *mri,WORD left,WORD top,WORD width,WORD height);
VOID MUI_RemoveClipping (struct MUI_RenderInfo *mri,APTR handle);
and
APTR MUI_AddClipRegion (struct MUI_RenderInfo *mri,struct Region *r);
VOID MUI_RemoveClipRegion (struct MUI_RenderInfo *mri,APTR handle);
do basically the same, once with coordinates and once with a struct Region.
Note that after MUI_AddClipRegion, you no longer need to worry about
freeing the structure, MUI_RemoveClipRegion will do this for you.
The MUI_AddXXX return a handle which must be passed to the MUI_RemoveXXX
function call. Adding clip regions cannot fail. You can nest clip regions,
MUI will automatically take care of that and "AND" new regions to existing
ones. Thus, the clipping calls work fine in virtual groups.
> I am trying to write a custom class that implements the ListView with
> horizontal scrollablity,
That's heavy stuff. In fact, MUI should offer this but due to lack of
time on my side, it still doesnt. :(
--
Greetings, Stefan
From: "Stefan Stuntz"
Date: Thu, 14 Dec 1995 11:15:26 +0100
X-Mailer: IntuiNews 1.3b Beta 3 (5.11.95)
Subject: Re: Clipping in SubClasses
Message-Id: <64540270@magic.informatik.tu-muenchen.de>
Organization: Home of MUI
Resent-Message-Id: <"O5R273.0.MO3.Eg_pm"@sunsite>
Resent-From: mui@sunsite.Informatik.RWTH-Aachen.DE
Reply-To: mui@sunsite.Informatik.RWTH-Aachen.DE
X-Mailing-List: archive/latest/65
X-Loop: mui@sunsite.informatik.rwth-aachen.de
Precedence: list
Resent-Sender: mui-request@sunsite.Informatik.RWTH-Aachen.DE
Content-Type: text
Content-Length: 298
X-Lines: 13
Status: RO
Boris Folgmann wrote in article
> > APTR MUI_AddClipping (struct MUI_RenderInfo *mri,WORD left,WORD
> top,WORD width,WORD height);
> > VOID MUI_RemoveClipping (struct MUI_RenderInfo *mri,APTR handle);
>
> When do I call them? Show/Hide?
Never. Only durig MUIM_Draw.
--
Greetings, Stefan
From: Jason S Birch
Message-Id: <199602090445.MAA10168@decadence>
Subject: Re: MUI FAQ
To: svermeul@suntzu.psg.datap.ca (Stephen Vermeulen)
Date: Fri, 9 Feb 1996 12:45:51 +0800 (WST)
In-Reply-To: <199602081714.KAA08466@alien.psg.datap.ca> from "Stephen Vermeulen" at Feb 8, 96 10:14:39 am
X-Mailer: ELM [version 2.4 PL25]
Mime-Version: 1.0
Content-Transfer-Encoding: 7bit
X-Lines: 80
Status: RO
Content-Type: text/plain; charset="US-ASCII"
Content-Length: 3083
> I would like to see:
>
> 1. Notes on clipping
> 2. Notes on writing custom classes
> 3. Pointers to source code examples for custom classes
> 4. Using BOOPSI in MUI
> 5. Corrections to the MUI docs (missing/obsolete attributes...)
> 6. Using datatypes with mui custom classes
Good, that's what I like to see. BTW, since I've already had to work
out the clipping deal for a previous question I got for the FAQ,
here's the answer I gave:
---
Ok, here's the easiest way:
Inside your MUIM_Draw method, having something along the lines of:
APTR clip = MUI_AddClipping(muiRenderInfo(obj), left, top, width, height);
where (left, top) are the starting co-ordinates, and (0,0) is the top
left of the object's area. width is the width of the clipping region,
and height is it's height.
When you have finished (again, still inside MUIM_Draw) you do:
MUI_RemoveClipping(muiRenderInfo(obj), clip);
Note that clip is the handle that was originally returned by
MUI_AddClipping(). That's it. You can nest clippings simply by calling
it again (with a different handle), MUI will take care of combining
them.
You can also use a struct ClipRegion. I've included Stefan's notes on
the subject at the end of this message.
As to why you need to do this, I'd say that it's because outside of
your MUI_Draw routine, MUI is free to do anything it wants with your
area. It can stick it into a virtual group, it can disappear
altogether (when iconified or the window is closed), anything. If
there were ClipRegions hanging around that MUI hadn't installed, I
imagine it would make all this rather difficult. I'd say it's the same
reason why you can't draw to your area outside of your MUI_Draw
routine.
Here are Stefan's notes:
APTR MUI_AddClipping (struct MUI_RenderInfo *mri,WORD left,WORD top,WORD width,WORD height);
VOID MUI_RemoveClipping (struct MUI_RenderInfo *mri,APTR handle);
and
APTR MUI_AddClipRegion (struct MUI_RenderInfo *mri,struct Region *r);
VOID MUI_RemoveClipRegion (struct MUI_RenderInfo *mri,APTR handle);
do basically the same, once with coordinates and once with a struct Region.
Note that after MUI_AddClipRegion, you no longer need to worry about
freeing the structure, MUI_RemoveClipRegion will do this for you.
The MUI_AddXXX return a handle which must be passed to the MUI_RemoveXXX
function call. Adding clip regions cannot fail. You can nest clip regions,
MUI will automatically take care of that and "AND" new regions to existing
ones. Thus, the clipping calls work fine in virtual groups.
---
> > APTR MUI_AddClipping (struct MUI_RenderInfo *mri,WORD left,WORD
> top,WORD width,WORD height);
> > VOID MUI_RemoveClipping (struct MUI_RenderInfo *mri,APTR handle);
>
> When do I call them? Show/Hide?
Never. Only durig MUIM_Draw.
-
From: ss37@irz.inf.tu-dresden.de (Sven Steiniger)
Date: Tue, 16 Jan 1996 11:38:19 +0100
Message-Id: <199601161038.LAA18730@irz102.inf.tu-dresden.de>
To: mui@sunsite.Informatik.RWTH-Aachen.DE
Subject: Window pattern
Resent-Message-Id: <"GBwuf.0.Gy.s0u-m"@sunsite>
Resent-From: mui@sunsite.Informatik.RWTH-Aachen.DE
Reply-To: mui@sunsite.Informatik.RWTH-Aachen.DE
X-Mailing-List: archive/latest/169
X-Loop: mui@sunsite.informatik.rwth-aachen.de
Precedence: list
Resent-Sender: mui-request@sunsite.Informatik.RWTH-Aachen.DE
Content-Type: text
Content-Length: 494
X-Lines: 18
Status: RO
Hello,
Did anyone know how to avoid that MUI draws a background-pattern into the
window ?
(I create a custom class (from mui-window-class). This install a new clipRegion
in the window and waits for draw-messages (MUI_Draw or my own PREVIEW_Draw)
and then it clear this Region and draw the new content. The problem is that
MUI first draws his window-pattern and then I come and clear this area. This
looks really bad and is very slow)
Sven Steiniger.
----
From: Jason S Birch
Message-Id: <199601161323.VAA15463@decadence>
Subject: Re: Window pattern
To: mui@sunsite.Informatik.RWTH-Aachen.DE
Date: Tue, 16 Jan 1996 21:23:00 +0800 (WST)
In-Reply-To: <199601161038.LAA18730@irz102.inf.tu-dresden.de> from "Sven Steiniger" at Jan 16, 96 11:38:19 am
X-Mailer: ELM [version 2.4 PL25]
Mime-Version: 1.0
Content-Transfer-Encoding: 7bit
Resent-Message-Id: <"negU23.0.Xi2.LQz-m"@sunsite>
Resent-From: mui@sunsite.Informatik.RWTH-Aachen.DE
Reply-To: mui@sunsite.Informatik.RWTH-Aachen.DE
X-Mailing-List: archive/latest/170
X-Loop: mui@sunsite.informatik.rwth-aachen.de
Precedence: list
Resent-Sender: mui-request@sunsite.Informatik.RWTH-Aachen.DE
X-Lines: 23
Status: RO
Content-Type: text/plain; charset="US-ASCII"
Content-Length: 935
> Hello,
>
> Did anyone know how to avoid that MUI draws a background-pattern into the
> window ?
> (I create a custom class (from mui-window-class). This install a new clipRegion
> in the window and waits for draw-messages (MUI_Draw or my own PREVIEW_Draw)
> and then it clear this Region and draw the new content. The problem is that
> MUI first draws his window-pattern and then I come and clear this area. This
> looks really bad and is very slow)
Perhaps you should be creating an Area or Group subclass and putting
that into the window to receive MUI_Draw, rather than the window
itself?
> Sven Steiniger.
> ss37@irz.inf.tu-dresden.de
--
Jason S Birch
From: "Stefan Stuntz"
Date: Tue, 16 Jan 1996 15:16:31 +0100
X-Mailer: IntuiNews 1.3b Beta 3 (5.11.95)
Subject: Re: Window pattern
Message-Id: <81318141@magic.informatik.tu-muenchen.de>
Organization: Home of MUI
Resent-Message-Id: <"M_sVk3.0.gs3.Vk4_m"@sunsite>
Resent-From: mui@sunsite.Informatik.RWTH-Aachen.DE
Reply-To: mui@sunsite.Informatik.RWTH-Aachen.DE
X-Mailing-List: archive/latest/171
X-Loop: mui@sunsite.informatik.rwth-aachen.de
Precedence: list
Resent-Sender: mui-request@sunsite.Informatik.RWTH-Aachen.DE
Content-Type: text
Content-Length: 783
X-Lines: 22
Status: RO
Sven Steiniger wrote in article
<199601161038.LAA18730@irz102.inf.tu-dresden.de>:
> Did anyone know how to avoid that MUI draws a background-pattern into the
> window ?
> (I create a custom class (from mui-window-class). This install a new
> clipRegion
> in the window and waits for draw-messages (MUI_Draw or my own PREVIEW_Draw)
> and then it clear this Region and draw the new content. The problem is that
> MUI first draws his window-pattern and then I come and clear this area. This
> looks really bad and is very slow)
If you set
#define MUIA_FillArea 0x804294a3 /* V4 ... BOOL */ /* private */
for an object, area class will not draw its background. This attribute
is private but will become public nex version and works since
muimaster.library V4.
--
Greetings, Stefan
From: "Stefan Stuntz"
Date: Tue, 13 Feb 1996 13:43:53 +0100
X-Mailer: IntuiNews 1.3b Beta 5 (3.1.96)
Subject: Re: New errors introduced in 3.2?
Message-Id: <81319257@magic.informatik.tu-muenchen.de>
Organization: Home of MUI
Resent-Message-Id: <"-LoYp1.0.2c4.4W88n"@sunsite>
Resent-From: mui@sunsite.Informatik.RWTH-Aachen.DE
Reply-To: mui@sunsite.Informatik.RWTH-Aachen.DE
X-Mailing-List: archive/latest/287
X-Loop: mui@sunsite.informatik.rwth-aachen.de
Precedence: list
Resent-Sender: mui-request@sunsite.Informatik.RWTH-Aachen.DE
Content-Type: text
Content-Length: 993
X-Lines: 26
Status: RO
Terje Pedersen wrote in article <1158.6616T1367T2188@login.eunet.no>:
> >> Also getting the visual area of the scroll group seems to cause
> >> problems as _mleft(virtualgroup)+_mwidth/_mtop+_mheight seems to
> >> include the scroll bar which I'm not too interested in..
>
> >Of course a scrollgroup contains the bars, thats why its a scrollgroup,
> >not a virtualgroup. Besides from that, I cannot quiet believe that MUIs
>
> Well, I want to know the exact portion of the virtual group that is visible
> and draw this part of the whole area.
Why? The virtual groups clips anyway, just draw everything you want in
your draw method. If you want to optimize your drawing, parse the
currently installed clip region in your window and only draw the
parts contained in the clip.
struct Region *clip = (_window(obj)->Flags & WFLG_WINDOWREFRESH) ? _window(obj)->WLayer->DamageList : _window(obj)->WLayer->ClipRegion;
if (!clip)
draw_everything();
else
draw_stuff_in_clip();
Greetings, Stefan